The Design of a Minimal Role Based Access Control System under the Windows Nt 4.0 Workstation Operating System

....................................................................................................................................................................2 Introduction................................................................................................................................................................2 Role Based Access Control Review ............................................................................................................................2 Concept of Role Based Access Control (RBAC)...................................................................................................2 Why RBAC? .........................................................................................................................................................3 RBAC Models and Frameworks ..........................................................................................................................3 Security Advantages of RBAC .............................................................................................................................4 Comparison between Groups/Roles and ACLs/RBAC ........................................................................................4 RBAC in Windows NT .........................................................................................................................................5 Windows NT Review .................................................................................................................................................5 Windows NT Design .............................................................................................................................................5 Windows NT Architecture....................................................................................................................................7 Windows NT Security...........................................................................................................................................8 Security Model......................................................................................................................................................8 Secure System Elements .......................................................................................................................................9 The Windows NT Registry .................................................................................................................................13 Final word on Windows NT security..................................................................................................................13 Minimal RBAC WinNT Design Specification...........................................................................................................13 Design Scope .......................................................................................................................................................14 Requirements for RBACM ..................................................................................................................................14 RBACM Implementation Language....................................................................................................................14 Implementation Details.......................................................................................................................................15 High Level Design...............................................................................................................................................15 Class Descriptions...............................................................................................................................................23 Conclusion ...............................................................................................................................................................23 Bibliography ............................................................................................................................................................24 Abstract Although role based access control (RBAC) has been used in a variety of computer systems for more than 20 years, it is beginning to attract increasing attention as a promising alternative to traditional discretionary and mandatory access controls methods. RBAC is a security model devised to simplify security administration and reviews by simplifying and streamlining the day-to-day tasks of security administrators. Research by Barkley (1997) has concluded that “an RBAC mechanism consisting of the role hierarchy, static separation of duty, and cardinality features of the model defined by Sandhu et al. (1996) can usually be implemented on a system that supports access control lists”. Therefore, as the Windows NT security mechanism supports access control lists, an RBAC administration tool could be developed to provide the benefits discussed above. The RBAC administration tool would allow security administrators to manage security at a high level from a single point of control. The administration tool would simply provide an administration layer through which the underlying security mechanisms are easily managed.Although role based access control (RBAC) has been used in a variety of computer systems for more than 20 years, it is beginning to attract increasing attention as a promising alternative to traditional discretionary and mandatory access controls methods. RBAC is a security model devised to simplify security administration and reviews by simplifying and streamlining the day-to-day tasks of security administrators. Research by Barkley (1997) has concluded that “an RBAC mechanism consisting of the role hierarchy, static separation of duty, and cardinality features of the model defined by Sandhu et al. (1996) can usually be implemented on a system that supports access control lists”. Therefore, as the Windows NT security mechanism supports access control lists, an RBAC administration tool could be developed to provide the benefits discussed above. The RBAC administration tool would allow security administrators to manage security at a high level from a single point of control. The administration tool would simply provide an administration layer through which the underlying security mechanisms are easily managed. Introduction This is the first of two companion papers describing the design and implementation of a minimal Role Based Access Control (RBAC) framework to work under the Windows NT 4.0 Workstation Operating System. These two papers are intended to provide a solid foundation for future investigation into higher level RBAC models that are active, rather than passive, in nature. This first paper documents the design phase of a project aimed at implementing a minimal RBAC scheme (RBACM) for Windows NT 4.0 Workstation. Ideally, this scheme would focus on integrating the RBAC framework at the operating system level. As recent interest in RBAC has focused on integrating RBAC at the application level (Sandhu et al. 1996), the application would advance current practices by providing facilities that are sufficiently flexible to support a wide range of applications with minimal customization. Described in this paper are the endeavors undertaken to determine how compatible and amenable it would be to implement an RBAC framework in Windows NT. This required a detailed investigation of the Windows NT security mechanism to identify the possibilities and best approach to incorporate an RBAC framework. The outcome of the project will be a security administration tool prototype to demonstrate the feasibility and restrictions of incorporating an RBAC framework into a Windows NT environment. This is documented in the second paper. The paper is divided into three (3) main sections: • A review of Role Based Access Control; • A review of Windows NT Security; & • The design specifications of RBACM for Windows NT 4.0 Workstation. Role Based Access Control Review Concept of Role Based Access Control (RBAC) Role Based Access Control (RBAC) is a security mechanism devised to assist and simplify security administration and review. The driving motivation of RBAC is to simplify security policy administration while facilitating the definition of flexible, customized policies. A Role Based Access Control Mechanism consists of three fundamental entities: • Roles are an encapsulation of rights, responsibilities and obligations; • Users are considered to the entities that interact with the system i.e. people, autonomous agent such as robots, immobile computers, or even network of computers) that interact with the system; • Operations (or permissions) represent a particular mode of access to a set of one or more objects that provide the ability to perform a certain task. In RBAC operations are associated with roles, and users are made members of roles. Each role defines a specific set of operations that the individual acting in that role may perform. The user acquires the permissions of the role in which they are a member. Therefore, the operations that a user is permitted to perform are based on the user's role. The relationships between users, Roles and operations is depicted in the following diagram : The use of double arrows indicate a many-to-many relationship. That is, users may be assigned to many roles and many operations may be assigned to a role. The Use of RBAC in Enterprises RBAC is ideally suited for use in organizations. The use of roles to control access can be an effective means for developing and enforcing enterprise-specific security policies that map naturally to an organization's structure. It allows and promotes security to be managed at a level that corresponds closely to an organization's structure and simplifies security management. In such an environment, roles are created for the various job functions in an organization and users are assigned roles based on their responsibilities and qualifications. Users can be easily reassigned from one role to another. Roles can be granted new permissions as new applications and systems are incorporated, and permissions can be revoked from roles as needed. Why RBAC? Currently, there are two commonly used types of access control: Mandatory Access Control (MAC) and Discretionary Access Control (DAC). Mandatory access control allows the administrators to set up policies and accounts that will allow users to have access to only the files and resources needed to successfully complete their job tasks. Discretionary access controls restrict access to objects based upon the identity of the user. The traditional mandatory and discretional access controls are frequently inadequate to meet the information security needs of many commercial organizations. DAC is too weak to control access to information assets effectively, while MAC is too rigid for most commercial purposes. RBAC has been proposed to address this issue. Recent resurgence of interest in RBAC has focused on general support of RBAC at the application level. In the past, and today, specific applications have been built with RBAC encoded within the application itself. Existing operating systems and environments provide little support for application-level use of RBAC. Such support is beginning to emerge in products, e.g. the ORACLE DBMS has had support for roles since ORACLE7. The challenge is to identify application-independent facilities that are sufficiently flexible, yet simple to implement and use, to support a wide range of application with minimal customization. RBAC Models and Frameworks A number of RBAC models have evolved over time to provide reference points for comparison with systems and models used by other researchers and developers. Although several models exist, Sandhu et al. (1996) defined the currently accepted IEEE family of role-based access control reference models to systematically address the diverse components of RBAC, and their interactions. Sandhu et al. (1996) defines the RBAC0 Model as the minimal set of characteristics required for an access control mechanism to be considered an RBAC mechanism. The RBAC0 Model has the following components: 1. Users, Roles, Operations, and Sessions; 2. Role/Operation Association (many to many); 3. User/Role Association (many to many); 4. User/Session Association (one to many); 5. Session/Role Set Association (one to one); Extended RBAC models usually include such things as : Cardinality The ability to restrict the number of users assigned to a role at a given time. Constraint Enforcement. Specifies the conditions that must satisfied in accordance with the security policy e.g., mutual exclusion of roles. These constraints and restrictions simply impose restrictions on acceptable configurations of different components of RBAC. Role Hierarchies; The ability for one role to inherit another role. Role hierarchies are a natural means for structuring roles to reflect an organization's lines of authority and responsibilities. Authorized Role Subsetting (ARS); A user may not be a member of a role at all times and in all circumstances depending on the constraints and restrictions implied by the security policy. With an ACL mechanism, if a user is a member of a group, then that user is a member of that group for every and all sessions established. In other words, a user is a member of a group at all times and in all circumstances. A feature of RBAC is that each session may be associated with a different active role set (ARS). This restricts the user from acting in all authorized roles in a given session. Security Advantages of RBAC A major purpose of RBAC is to facilitate security administration and security review by simplifying and streamlining the day-to-day tasks of security administration. RBAC provides a high level, single point of control, security tool which reduces the complexity and cost of security administration. Very importantly, RBAC also provides the ability to articulate and enforce enterprise-specific security policies and to streamline the typically burdensome process of security management. This is the focus of the project that will be described later in this paper. Although RBAC is policy neutral, it directly supports three several well-known security principles: least privilege, separation of duties, and data abstraction. Least Privilege The principle of least privilege requires that a user be given no more privileges than necessary to perform their job. RBAC supported this principle by allowing only those permissions required for the tasks modeled by the role to be assigned to role. In non-RBAC implementations this is often difficult or costly to achieve. Separation of duty (Static & Dynamic) Static separation of duty controls membership of mutually exclusive roles, i.e. a user cannot gain membership to a role if the role mutually exclusive with another role for which the user already possess membership. RBAC can model this principle either statically or dynamically. By ensuring this principle statically a user is authorized as a member of a role only if that role is not mutually exclusive with any of the other roles for which the user already possesses membership. Dynamically restricts the user from having mutually exclusive roles active in the same session. Data Abstraction Data abstraction is supported by means of abstract permissions such as credit and debit for an account object, rather than the read, write, and execute permissions typically provided by the operating system. Comparison between Groups/Roles and ACLs/RBAC Although a simple RBAC can be shown to be no different from a group ACL mechanism (Barkley 1997) the concept of a group and a role should not be confused. A group is simply a named collection of users which simplifies security administration by allowing security rules to be specified for one group rather than each individual user. In contrast, a role is collection of both users and permissions. The role serves as an intermediary to bring users and permissions together. While this subtle difference between groups and roles simplifies security administration, RBAC models also provide features that most ACLs do not. In particular, RBAC models may include role hierarchies (situations where roles can inherit permissions from other roles) and constraints (which impose restrictions on acceptable configurations of the different components of RBAC). These features can be used to enforce security policies that include separation of duties and delegation of authority. Another feature that often distinguishes RBAC models from ACL mechanisms is the inclusion of features known as Authorized Role Subsetting. With authorized role subsetting a user may a establish a session with a subset of the role authorized for the user. This subset is often referred to as the active role set (ARS). During a session, the user may successfully perform any operation permitted by the roles in the current ARS. In other words, a user may not be a member of a role at all times and in all circumstances. This is in contrast to an ACL mechanism where a user is a member of all the groups they are assigned for every and all sessions. The following table shows how an RBAC model can be explicitly defined in an ACL environment. ACL Based Role Based Creates groups of individuals according to their responsibilities necessary to meet the goals of the organization. Creates roles based on the responsibilities necessary to meet the goals of the organization. Associate with the groups the permissions necessary to carry out their responsibilities Associates these roles with the permissions necessary to carry out these roles. Associates these groups to individual. Associates these roles to individuals. Therefore, given an access control policy described using ACL, the equivalent access control policy can be constructed using RBAC by associating a role with the user if that user is a member of the group that maps to that role. Hence, a very simple RBAC model is equivalent to an ACL mechanism from the point of view that any access control policy described using ACL can be described by RBAC. RBAC in Windows NT Research by Barkley (1997) has concluded that “an RBAC mechanism consisting of the role hierarchy, static separation of duty, and cardinality features of the model defined by Sandhu et al. (1996) can usually be implemented on a system that supports access control lists”. Therefore, as the Windows NT security mechanism supports access control lists, an RBAC administration tool could be developed to provide the benefits discussed above. The RBAC administration tool would allow security administrators to manage security at a high level from a single point of control. The administration tool simply provides an administration layer through which the underlying security mechanisms are easily managed. Ideally, the RBAC administration tool would focus on integrating the RBAC framework at the operating system level. As recent interest in RBAC has focused on integrating RBAC at the application level (Sandhu et al. 1996), the application would advance current practices by providing facilities that are sufficiently flexible to support a wide range of applications with minimal customization.